home *** CD-ROM | disk | FTP | other *** search
/ ftp.cs.arizona.edu / ftp.cs.arizona.edu.tar / ftp.cs.arizona.edu / icon / newsgrp / group94b.txt / 000003_icon-group-sender _Fri Aug 19 13:35:02 1994.msg < prev    next >
Internet Message Format  |  1995-02-09  |  3KB
  1. Received: by cheltenham.cs.arizona.edu; Fri, 19 Aug 1994 07:25:58 MST
  2. To: icon-group-l@cs.arizona.edu
  3. Date: Fri, 19 Aug 1994 13:35:02 GMT
  4. From: mcarroll@watson.ibm.com (Mark Chu-Carroll)
  5. Message-Id: <MCARROLL.94Aug19093502@shamrock.watson.ibm.com>
  6. Organization: IBM T.J. Watson Research
  7. Sender: icon-group-request@cs.arizona.edu
  8. References: <330a3u$3vq@shum.cc.huji.ac.il>
  9. Subject: Re: Simple syntax? A definition?
  10. Errors-To: icon-group-errors@cs.arizona.edu
  11.  
  12.  
  13. >>>>> "Zvi" == Zvi Lamm <mslamm@pluto.cc.huji.ac.il> writes:
  14. In article <330a3u$3vq@shum.cc.huji.ac.il> mslamm@pluto.cc.huji.ac.il (Zvi Lamm) writes:
  15.  
  16. Zvi> Following the recent thread on perl vs. Icon, and posts about
  17. Zvi> UNIX *tools* I started thinking on how one can define what are
  18. Zvi> the good qualities a synatx should have.  It appears to me that
  19. Zvi> what counts is simplicity. A simple syntax would be one that can
  20. Zvi> easaly be built (NOT parsed) by programs (so that the language
  21. Zvi> can be used as a tool interface). It would also be easy for
  22. Zvi> humans (that's us!) to learn and use.
  23.  
  24. Zvi> Does anyone have suggestions on how to define this in a more
  25. Zvi> mathematical or precise way? I thought about YACC
  26. Zvi> clauses/sentence. But I am not sure it's enough because the YACC
  27. Zvi> approach narrows you down to LALR.
  28.  
  29. Zvi> I thought one criterion can be PROXIMITY - that is that
  30. Zvi> semantically related elements should be near each other.  Any
  31. Zvi> others?
  32.  
  33. I've been thinking about this somewhat lately, because my dissertation
  34. work involves adding parallel programming constructs to sequential
  35. languages, and I want to do so in a *clear* way.
  36.  
  37. The things that I've come up with so far are:
  38.  
  39. <1> Unambiguous - for a human reader, it helps a *lot* if there's only one
  40.    correct reading of an element. 
  41.  
  42. <2> Orthogonal - different constructs should look different. (closely
  43.   related to <1>. If I look at a construct, I should be able to tell what
  44.   it does with minimal knowledge about context. if x = a is an assignment
  45.   statement, then x=a shouldn't also be a comparison in a different context.)
  46.  
  47. <3> Minimal - the less "noise" there is in the syntax the better. (ie,
  48.   COBOL is *bad*, because it's very hard to isolate the meaningful
  49.   text from all of the excess garbage.)
  50.  
  51. <4> Proximity - I agree with you, it's very important that related elements
  52.    be near each other. 
  53.  
  54. <5> Seperation - clauses should be visibly seperated. (This applies to
  55.    things like the different branches of an if statement. Lisp style
  56.    if's can be bad, because it's hard to see where the "then"
  57.    part ends and the "else" part begins.
  58.  
  59. <6> Legible - using a large number of bizzare symbols makes a program
  60.   much harder to read. (Look at a one-liner in APL, compared to a 
  61.   program in J with the primitives aliased to english words. Both 
  62.   can provide a beautiful, elegant solution to a problem. But almost
  63.   anyone can read the J program given a 5 minute introduction to the
  64.   language, and the APL program can take an expert time to decode.)
  65.  
  66.     <MC>
  67.